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ABSTRACT 



A network match making system and method is used to 
match users of a multi-user networked application. Each 
user is associated. with a client computer connected to the 
network. Clients are selected based on attributes of their 
users, the clients, servers, and/or communication links. The 
network match maker works with three different forms of 
network applications: peer-to-peer, multiple clients to a 
single server, and multiple clients to multiple servers. In one 
late server binding method, a set of computer objects is 
created. The set of computer objects has a plurality of client 
instances of client computer programs together with a server 
instance of a server computer program selected from a set of 
server instances. A match maker receives from a first client 
instance a first request to be joined into the set of computer 
objects. The first request has first client attributes associated 
with the first client instance. The match maker selects a first 
server subset of the set of server instances in response to the 
first request based on the first client attributes and creates the 
set of computer objects consisting of the first client instance. 
The match maker augments the set of computer objects with 
a second client instance of a client computer program. In 
particular, the match maker receives from the second client 
instance a second request to be joined into the set of 
computer objects. The second request has second client 
attributes associated with the second client instance. The 
match maker removes a second server subset from the first 
server subset in response to the second request based on the 
second client attributes and adds the second client instance 
to the set of computer objects. Finally, a member of the 
second server subset is added to the set of computer objects 
based on attributes associated with each member of the set 
of computer objects. 

18 Claims, 9 Drawing Sheets 
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OBJECT-ORIENTED METHOD FOR The present invention presents a network match making 

MATCHING CLIENTS TOGETHER WITH system that solves the above described problems in the prior 

SERVERS ACCORDING TO ATTRIBUTES art and provides an automated means for users to be matched 

INCLUDED IN JOIN REQUEST with one another for a networked application. The network 

s match maker not only takes into account the users prefer- 
CROSS-REFERENCE TO RELATED cnces and attributes, but the attributes of the client computer, 

PROVISIONAL APPLICATION lne application, any optional servers needed by the applica- 

This patent application claims the benefit of U.S. Provi- tion and the properties of the communications links between 
sional application Ser. No. 60/013,812, filed on Mar. 21, the clients and the clients and any optional servers. 

1996, now abandoned. 10 These and other features and advantages of the present 
BACKGROUND OF THE INVENTION invention will become apparent from the following detailed 

description of the invention and accompanying drawings. 

Computer networks are widely used to connect multiple 
computer systems together for communicating and sharing BRIEF DESCRIPTION OF THE DRAWINGS 

information. Computer networks can also be used to imple- 15 _. T _ _ , _ , . ... 4 4 . , 

u . v , „ 1# . , . FIG. 1 is a flow chart showing the interaction between a 

ment multi-user applications that allow multiple users to - . . , . , , . & , ..... 
. . S c * first client and a match maker m accordance with the present 

share in the operation of a computer program. Common invention 
examples are video and teleconferencing applications, 

online multiplayer games which allow multiple users to play FIG 2 is a flow chart showin g the interaction between a 

a game with one another and online chat environments. A 20 second f^ent and a match maker in accordance with the 
problem common to all such multi-user network applica- present invention. 

tions is providing an eflicient way to bring together groups FIG. 3 is a flow chart showing the interaction between 
of users to join in the running of a multi-user application. clients and the match maker of FIGS. 1 and 2 in accordance 
Today, the known solutions deal only with the users require- with the present invention. 

ments such as which other people they wish to be matched 25 FIG. 4 is a flow chart showing measurement of commu- 

with. These solutions provide little more than manual meth- nication attributes in accordance with the present invention. 

ods for the users to select the other users that they wish to FIG. 5 is a flow chart showing the steps in matching in 

be matched with. This is workable only when there are accor dance with the present invention. 

reasonable numbers of users in the pool of all users. It rT „ , , _ a Li .- 4 • tI _ » 

, * i * i t , r * c „„ FIG. 6 and 7 are flow charts showing termination methods 

becomes unworkable when there are large numbers ot users 30 . , . 4 , t . f- 

, , it _ * . , . « . , b . 4 - t in accordance with the present invention, 

and when the application has special requirements for net- r 

work performance or capabilities of the client and/or server FIG 8 is a flow chart showin g tQe interaction of clients, 
computer systems used to implement the application. servers and a match maker in accordance with the present 

Networked applications for multiple clients exist in three invention, 

forms. Peer-to-peer applications are executed by multiple 35 FIGS. 9-10 are flow charts showing the use of commu- 
client computers with no server or servers required. All nication attributes in accordance with the present invention, 
communication traffic during the execution of the applica- FIG. 11 is a flow chart showing the matching operation of 
tion is directed between the clients. Other multiple client the match maker in FIG. 8. 
networked applications use a single server system. The 

server may execute some portion of the application that is to 40 DETAILED DESCRIPTION OF THE 

be shared by all of the clients while the remainder of the INVENTION 
application is executed on the clients. The server can also act xhe present invention involves a network match making 
as a communications collection point. Some or all of the process running on a server system on a network that is used 
communication traffic is between each of the clients and the by clients to be matched into matched sets of clients for a 

server. The clients may additionally communicate with one ^ multi . uscr application. When the networked application 
another as needed. Finally, multiple servers may be used in operates in a networked system with multiple servers that 
a multiple client application. Similar to the case of a single may be used by the application, the network match maker g , 
server, a portion of the application may be executed on the matches a server to the matched set of clients. A key tkvdts/qQNt/f 

servers. The multiple servers can also provide communica- id ea behi nd the present invention is that clients and the J I I 

tions collection points for the clients. 50 server are matcnea not only on the basis ol user attributes, TH^TCMia 
SUMMARY OF THE INVENTION out also on me Dasis ot client server a nd application I 

T , , , , . auriDutes and on network performance characteristics sf 

In the present invention a network match making system mM ag bandwldthi Ia(ency and packet | oss .tfvL-.llA 

is used to create matched sets of users of a multi-user . 4 r OAAvllOW** 0 

networked application. Each user is associated with a client 55 n u ^ 

computer connected to a network. Also on the network is a ^ network match maker matches clients and a server 
server computer which executes a software process that is mto matched sets by comparing the attributes of the user, the 
the network match maker. In some implementations there clie[lt > ^ server and the properties of the network links 
are one or more additional servers that are also used for between them to the requirements of the application, 

supporting the networked application. The clients are 60 Client and user attributes 

selected into matched sets based on attributes of their users, The user attributes include the obvious characteristics of 
the clients, application class and instance, the attributes of the user that are relevant to the networked application. Some 
the servers and the properties of the client-to-client and examples include things such as skill level, age, people the 
client-to-server communications links. The network match user doesn't want to be matched with. For the sake of a 

maker works with three forms of network application imple- 65 clearer discussion, the user and client attributes will be 
mentation: peer-to-peer, multiple clients to a single server lumped into one group, and is referred to as "client 
and multiple clients to multiple servers. attributes." Client attributes describe the capabilities of the 
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client computer system. The performance of the client or there may be a voting scheme between the users sharing 

computer, tie type and performance of its network link and moderator powers. It is also possible to imagine a mixture of 

the types and versions of the networked applications that are match maker and user moderator powers. Some of the 

installed on it are all reasonable examples of client instance attributes might be set by the match maker and 

attributes. 5 others by one or more users that join the match offer. 

Application attributes User Created Match Offers 

The application attributes are the requirements of the Users may create their own specific offers to other users 

networked application. Examples of these requirements to match with. These are called match offers. To create a 

include the type and performance of the client, the type and match offer, the user will choose one application for which 

performance or any necessary server and the required prop- 10 to create a match offer. The offer will inherit the class 

erties of network links between the clients and between the attributes of the application, but the user may add additional 

clients and the server. Application attributes come in two instance attributes for their specific match offer. The user 

forms, class and instance. The class attributes of an appli- that created the original match offer will be considered the 

cation apply to any instance of the application. The net- moderator of that offer and will be the only one that is able 

worked match maker operates in an environment where 15 to select the instance attributes of the match offer. Other 

there will be multiple instances of each application. When an users will browse these match offers, examine their 

instance of an application is created, it inherits the class attributes, select an offer that they find acceptable and 

attributes while additional instance attributes may also be attempt to join that offer. The match maker will compare the 

applied. These instance attributes may simply override some client attributes and the communications attributes of any 

of the class attributes inherited by the instance, while others 20 relevant communication links to the required instance 

may be specific only to application instances. attributes. If they do not match the required attributes of the 

Server attributes match offer, the match maker will prevent the user from 

Example of static server attributes include the type and joining the match offer. If they do match, the new client will 

performance of the server system, types and versions of any J oin the offer and will be added to the matched set of clients 

networked application software that is installed on the associated with the offer. As clients attempt to join the match 

server. Dynamic attributes include the current load on the offer, the match maker will also compare their attributes with 

server Considering the current load on the server when those of the other clients to make sure that the user attributes 

assigning application instances to a server is a way to effect compatible before a client is allowed to join the match 

dynamic load balancing on the servers in a multiple server offer. Once enough clients have joined the match offer, the 

system. moderator can select to launch the application. 

Communications attributes How ^ network match maker determines how the prop- 
Communications attributes are the properties of the net- erties of any relevant communications links affect which 
work link between two computer systems. These will chents can join a match offer depends on the architecture of 
include the links between clients and links between clients 35 the ^tworked applic ation and is described m the following 
and a server The properties of network links will include the 1 J u^kSLK -TD 
available bandwidth, the latency and the packet loss rate. Peer-to-peer^ ^ \ 
Many networked applications will have certain minimum When the client requests to join a match offer, the network 
requirements for bandwidth and maximum requirements for match maker will ask the new client to measure the prop- 
latency. There are other metrics of communication perfor- 40 erties of the communications links between the new client 
mance that may be valuable measures of the properties of a and all of the existing clients that already are members of the 
communications link between two computer systems that match offer. The properties of the communications links 
also can be used. between the new client and the existing clients that are 
Types of Matches members of the match offer will be returned to the match 
The network match maker forms matched sets of users by 4 5 maker m a vector of network properties. These properties 
either automatically matching users into matched sets or will be compared to the requirements of the instance 
allowing users to create match offers that other users may attributes for the match offer. The application will have its 
browse and then choose to join until full matched sets are own class attributes for communications properties of the 
completed. In both of these cases, the match maker will network links between the peers needed to run the applica- 
choose a server for the matched set if multiple servers are so ^on. The creator of the match offer may override these 
available and the networked application requires it. Auto- attributes to create instance attributes for the properties of 
matic matching is a simple variant of user created match the communications links between the peers. If the client 
offers, so the user created match offer case is discussed first. attributes and the attributes of the communication links 
In both of these types of matches, there is the concept of matcn the requirements of the application instance, the new 
a moderator. The moderator is the agent that chooses the 55 client ™& be j° med mto ^ match offer - 
instance attributes of a match offer. When the match offer is Multiple clients to a single server 
created, it inherits the class attributes of the application. The In this case, the server is assumed to have all of the 
moderator may then modify the attributes to create the necessary properties to host the necessary portions of the 
match offer instance attributes. When the application is application. As with the peer-to-peer case when a client 
launched for a match offer, it does so using the instance 60 requests to join a match offer the network match maker will 
attributes of the match offer. In user created match offers, the ask the new client to measure the properties of the commu- 
most simple case is that the user that created the offer is the nications links between the new client and all of the existing 
moderator. In automatic matches, the match maker itself is clients that already are members of the match offer. These 
the moderator. Other possibilities exist. It is possible for properties will be returned to the match maker as a vector of 
some or all of the users in a match offer to share powers of 65 communications properties which will be compared to the 
the moderator. They may be able to override each others requirements of the application instance attributes for com- 
attribute choices so that the last setting of the attributes wins, munications properties of client-to-client links. In this case 
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the network match maker will also ask the new client to 
measure the properties of the communications link between 
the new client and the single server. The properties of this 
link are also matched to the instance attributes for commu- 
nications properties of the client-to-server link. If all 5 
matches properly, the new client is allowed to join the match 
offer. In many multi-user networked applications that use a 
single server all client-to-clieat communications will be 
through the server, so there will be no direct client-to-client 
communications. In these cases, only the properties of the Q 
communications links from the clients to the server will be 
relevant. 

Multiple clients to multiple servers 

With multiple server systems, the situation becomes more 
complex. Not only must the system consider the properties 15 
of the communications links between the clients and the 
multiple servers, but additionally the attributes of the server 
systems. Not only must the network match maker match the 
clients into matched sets, it also must determine which of 
multiple server systems is to be associated with each 20 
matched set of clients. In the discussion here, it is assumed 
that the match maker will ultimately choose a single server 
to be matched with each matched set of clients associated 
with a match offer. The approach outlined here can be easily 
generalized to support applications that required multiple 25 
servers to be used when running a multi-user application. 
However, there are two server selection policies that the 
network match maker can use to select a specific server for 
a match offer called early server binding and late server 
binding. 30 

When a client asks to join a match offer for a particular 
application, the network match maker asks the client to 
measure the properties of the communications links between 
itself, all of the other clients that are members of the matched 
set associated with the match offer and all of the server 35 
systems that are available for that application. The servers 
available for that application are a subset of all of the servers 
based on the attributes of the servers and the attributes for 
server requirements for the match offer instance. When a 
client creates a match offer they may specify instance 40 
attributes for the application that override or add to the 
application class attributes. This may further limit the subset 
of server systems that can support the application. When a 
new client requests to join the match offer, the network 
match maker will compare the client attributes to the 45 
required attributes of the match offer. If they match, the 
network match maker will then compare the properties of 
the relevant communications links to the requirements of the 
specific match offer. 

With early server binding, the network match maker 50 
chooses the server from the qualified subset of servers using 
only the properties of the communications links between the 
creator of the match offer and the qualified servers. If 
multiple servers have communications links to the creator of 
the match offer that meet the requirements of the match 55 
offer, the network match maker will choose one based on 
some defined criteria. A reasonable criterion would be the 
best performance, but other criteria would be possible. As a 
new client attempts to join the match offer, the match maker 
compares the client attributes, the properties of the commu- 60 
nications links between the new client and the existing 
members of the match offer and from the new client to the 
selected server. If all of these attributes and communications 
properties meet the requirements of the match offer, the 
client is allowed to join. While early server binding is the 65 
simplest server selection policy, it may not always result in 
the best server selection for all of the clients and it may 
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prevent some clients from joining a match offer that they 
could have joined if a different server had been selected. 
This is clearly the case if network latency is one of the 
important properties of a network link. With early binding, 
a qualified server with the lowest communications latency to 
the client creating the match offer will be chosen. This 
latency may be far lower than the latency required by the 
match offer. The latency requirement of the match offer 
creates a virtual "sphere" around the chosen server. Clients 
that match the attributes of the match offer that are within the 
latency sphere centered around the chosen server will be 
able to join the match offer. Depending on the location in 
latency "space" of other qualified servers and other clients, 
another server may be a better choice that will not only allow 
the creator of the match offer, but more clients than the 
original server choice. 

Server late binding eliminates this issue, but is more 
complex. With server late binding the network match maker 
maintains a pruned list of qualified servers for a match offer. 
The clients join the match offer in the usual way. The 
attributes of the new client are first compared to those of the 
match offer. If they match, the properties of the network 
links are compared. The match maker compares the prop- 
erties of the network links between the new client and the 
member clients of the match offer to the instance attributes 
of the match offer. If they match, the properties of the 
network links between the client and the pruned list of 
servers is compared to the instance attributes of the match 
offer. If one or more of the communications links between 
the new client and the pruned list of servers meet the 
requirements of the match offer the client is allowed to join 
it. The network match maker then prunes the list of servers 
associated with the match offer to eliminate any for which 
the properties of the communications link from the new 
client to the server did not meet the instance attributes of the 
match offer. This will guarantee that the existing clients that 
are members of the match offer will continue to meet the 
requirements of the match offer. When the moderator finally 
chooses to launch the game, there may be more than one 
server in the pruned server list. The network match maker 
will select a final server using a selection criteria that it 
chooses. Typically this selection criteria will choose the 
server with the best overall communications properties to all 
of the client that are members of the match offer. In many 
network applications, there will be no direct communica- 
tions between the clients. There will only be communica- 
tions between the clients and a server. In this case there will 
be no need to measure properties of the communications 
links between the clients and so this will not be part of the 
match making process. 

Automatic Matches 

Automatic matches are very similar to user created match 
offers except that the users ask the match maker to create 
automatic match offers to match them with. A user specifies 
an application to run and requests an automatic match. The 
network match maker looks at the users requesting an 
automatic match of the same application and attempts to 
organize them into matched sets. The match maker creates 
automatic match offers to which it matches the clients. As 
part of creating an automatic match, the user may be given 
the ability to specify modifications to the attributes of the 
automatic match offer instance of an application. As an 
example a user might ask for an automatic match for a game 
with only expert players. 

When a client requests an automatic match, match maker 
will compare the client attributes and communications prop- 
erties of the requester as applicable to the attributes of the 



03/23/2004, EAST Version: 1.4.1 



5,828,843 



8 



existing automatic match offers. If the client attributes and 
applicable communications properties of the client match an 
automatic match offer, the client will be entered into the 
matched set of clients associated with the match offer. If the 
attributes of a client and applicable communication proper- 5 
ties do not match the instance attributes of the automatic 
match offer, the match maker will move on to the next 
automatic match offer. This continues until the client has 
been matched to an automatic match offer, or there are no 
more automatic match offers. If the new client has failed to 
match any of the automatic match offers, the network match 
maker creates a new automatic match offer and joins the new 
client with it. When a particular automatic match offer 
contains enough clients as required by the attributes, the 
match maker causes an instance of the application to be ^ 
launched. The network match maker will also support a 
reasonable time-out period for the launching of automatic 
match offers. 

The particular cases of peer-to-peer, multiple clients to 
single server and multiple clients to multiple servers are all ^ 
handled in this frame work as they would with user created 
match offers, A final detail of automatic match offers is that 
users that are manually browsing match offers will also see 
and be able to join the automatic match offers. 

Examples of Communications Attributes 25 

The most important communications attributes are 
bandwidth, latency and packet loss rate. Other attributes of 
communications networks may be important in some 
applications, but these are the most broadly important 
attributes. Below are examples of how these attributes 30 
would be used by the match maker for matching clients and 
servers to a match offer. For the purposes of these examples, 
the discussion here relates only to how the communications 
attributes are used in the match making process. The other 
client and server attributes will be ignored. 35 

Bandwidth is the data rate that can be supported by a 
particular network link. Networked applications will have 
requirements for the data rates that they need to send 
between clients or between clients and a server. Consider as 
an example an application that be operated with or without 40 
speech communications between the clients. When used 
with digital speech, the speech data consumes a significant 
amount of data bandwidth. Further consider that the appli- 
cation is a peer-to-peer application with no need for a server. 
In this example, a user creates a match offer for this 45 
application and sets an instance attribute for this match offer 
to enable speech communications. When a new client 
requests to join the match offer, the match maker will ask the 
new client to measure the bandwidth between the new client 
and all of the clients that are already members of the match 50 
offer. If the bandwidth between the new client and any one 
of the existing members of the match offer is too low to 
support the bandwidth requirements of the application when 
speech is enabled, the match maker will see that the client 
attributes for communications bandwidth to one of the 55 
existing clients does not match the instance attributes of the 
match offer for client-to-client communication bandwidth. 
The new client will therefore be prevented from joining the 
match offer. The same client may be allowed to join a match 
offer for the same application when the match offer instance 60 
specifies that client-to-client speech is not enabled. This will 
be true if the match offer instance attributes for client-to- 
client bandwidth are equal to or lower to the bandwidth from 
the new client to each of the existing client members of the 
match offer. 65 

Latency is another important communications attribute. 
Latency is the time for a communications data to travel over 



a network link from one system to another Many interactive 
applications will have strict requirements for communica- 
tions latency that if not met will prevent the application from 
operating properly. Total latency on a communications link 
will be the sum of many factors including the propagation 
time of signals over long distances. The other factors can 
generally be minimized or reduced, but propagation delays 
are set by physical laws. Imagine a highly interactive game 
that is played between multiple clients through a server. 
Each client in a game instance sends and receives its 
communications data to the other clients through the server. 
In this example, also consider that the pool of potential 
clients to play the game are spread over a wide geographic 
area and that there are multiple servers also spread through 
the same area. The example game has strict latency require- 
ments for the communications delay between the clients and 
a server used for a game instance. If the latency between a 
client and the server exceed this, the quality of the game play 
for the client or all of the clients in the game instance may 
be unacceptable. In this example, the match maker must not 
only match clients together into matched sets, but it also 
must match each matched set of clients to a specific server. 
As described earlier there are two methods of matching the 
server to a group of clients:early server binding and later 
server binding. With early server binding, the match maker 
will choose the server that has the lowest measured latency 
to the first client in the match offer. As each new client 
attempts to join the match offer, the match maker will ask the 
client to measure its latency to the server that has been 
selected for the match offer. If the measured latency meets 
the requirement of the match offer instance for latency, the 
new client will be allowed to join. The end result is that all 
of the clients that join the match offer will meet the require- 
ments for latency of the match offer instance. With server 
late binding, when the match offer is initially created, the 
match maker will create a list of all of the servers that match 
all of the instance attributes of the match offer. As clients 
join the match offer, the match maker will ask the clients to 
measure their latency to each of the servers in the list. The 
new client will provide this vector of measured latencies to 
the match maker. Each latency in the vector will be com- 
pared to the latency attribute requirements of the match 
offer. If one or more the latency vector elements meet the 
latency requirements of the match offer, the new client will 
be allowed to join it. The match maker will then prune from 
the server list associated with the match offer any servers 
whose corresponding latency vector elements for the new 
client did not meet the requirements of the match offer. Once 
all of the desired clients have joined the match offer, there 
may be more than one server that are in the pruned list. The 
match maker will then use some criteria to select a single 
server. One criteria would be to choose the server that 
minimized the average latency between that server and all of 
the clients. Another criteria would be to minimize the 
latency differences between each of the clients and the 
server. 

In a well managed network, most of the latency between 
two points in the network will come from the network 
propagation time. In both the early and late server binding 
cases, this will mean that the clients will tend to be matched 
to servers that are located near to them in the network. If the 
network tends to minimize the lengths of the network 
connections, this will result in clients being matched to 
servers in their geographical vicinity. 

Packet loss rate, is the rate at which data is lost during 
transmission in a network. Most networks transmit data in 
discrete units called packets or frames. Some networking 
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protocols such as UDP do not provide guaranteed data 
delivery so it is up to the application to either be tolerant of 
transmission loss or provide a means to retransmit the data. 
Other networking protocols such as TCP/IP do provide 
guaranteed delivery. However, when a packet is lost this 
must be signaled to the sender and the transmission retried. 
Unfortunately, this takes time and introduces a large delay 
before the lost packet can be recovered. In some 
applications, this delay causes more problems than the loss 
of the data. Therefore, many interactive applications will 
have requirements for maximum tolerated packet loss rates. 
This then becomes an important attribute of a network link 
that an application may want the match maker to consider as 
part of matching clients to a match offer and a server to 
matched set of clients. This attribute will be used in a similar 
fashion to the other network attributes. 
Generalizations to the invention 

The previous discussion of client-server applications only 
considers the cases where this is only a single server or the 
match maker chooses a single server from multiple servers 
to match to a match offer. It is also possible in the case where 
there are multiple servers that the application may require 
multiple servers. Consider an application that has two forms 
of data that it transmits through the network. As an example 
consider an interactive game that supports speech commu- 
nications between players. It will transmit game information 
and user speech data that it separates into two separate data 
streams that flow between the clients and two different 
servers. One server will handle the game data while the other 
the speech data. This allows the server that handles the 
speech data to be equipped with special capabilities specific 
to processing the speech data prior to routing it to the clients 
that are to receive it. 

With this arrangement, the application will require two 
servers, each with unique attributes. Since the game data and 
speech data will have different bandwidth, latency and 
packet loss requirements, the application will have separate 
requirements for each of the two data streams. This will 
mean that there will be two sets of application attributes for 
properties of the network links between the clients and the 
servers. During the match making process in this example, 
the match maker will ask a client requesting to join a match 
offer to measure the properties of the network links from the 
client to each of the two servers. For the client to be allowed 
to join the match offer, both sets of network properties must 
match the instance attributes of the match offer for the 
application requirements for each of the network links from 
a client to the two servers. 

In the prior discussions it has been assumed that once a 
sufficient number of clients have joined a match offer for an 
application that the application is launched with all of the 
clients that have successfully joined the match offer. The 
launch may be triggered by a moderator in a user created 
match offer or may be triggered by the match maker when 
enough clients have been matched to an automatic match 
offer. 

There is another important case of a persistent applica- 
tion. This is an application that allows clients to join and 
leave it during its operations. In this case, the game may be 
launched by a single client or automatically by the match 
maker. In this case, the running application also embodies a 
match offer. If the application requires a server or servers, 
they are chosen at the time that the application is launched. 
The server is chosen based on its attributes and the required 
attributes of the application. When a client requests to join 
the running application, the attributes of the client are 
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compared to the required attributes of the application. The 
properties of the appropriate network links are measured and 
matched to the required network attributes of the applica- 
tion. If all matches, the new client is allowed to join the 
running application. At a later time the client may leave the 
application. This situation is the same as clients joining a 
match offer with early server binding. 

DESCRIPTION OF AN EMBODIMENT OF THE 
INVENTION 

Although the above description of the present invention is 
entirely enabling of the invention generally and of this 
embodiment in particular to a practitioner ordinarily skilled 
in the arts, as an aid to more quickly understanding the 
invention it is useful to consider in some detail an embodi- 
ment that contains only a relatively small subset of the 
invention and which is therefore relatively simple to 
describe and also is relatively quick and easy to understand. 

The present embodiment relates to matchmaking for Peer 
to Peer games that is to say games that play without the use 
of any Servers even though the matchmaker is itself imple- 
mented as at least one Server. The network that this par- 
ticular embodiment uses is the well known Internet which 
uses the also well known Internet Protocols (such as TCP/IP 
and UDP/IP). Moreover, for simplicity since the present 
embodiment is described only by way of illustration of the 
above described invention, only a relatively few of the 
possible alternatives are incorporated into this particular 
embodiment. 

The term computer program is commonly abbreviated to 
program. A matchmaker server program is used, an execut- 
ing instance of this program (abbreviated to MM) resides on 
a server computer. The concepts of server computers and 
executing instances of programs are well known in the 
computing arts. Each computer user (abbreviated to user in 
this embodiment) launches an instance of a client computer 
program on his computer which computer is then a client 
computer for the time being. 

Referring to FIG. 1, in step 11, an instance of a client 
program (CL1) sends a request to the MM, the use of 
message exchanges by means of Internet communications to 
send requests is well known in the data communications and 
computing arts. The request asks the MM to create a game 
offer and the request includes attributes of the various game 
and match preferences chosen by the user together with 
intrinsic attributes of the requested type of game and 
attributes of the hardware and software installed on the 
user's computer. The intrinsic attributes of the game include 
limiting values for communications attributes of links 
between users' computers. In step 12, the MM receives this 
request. A well known intrinsic feature of the Internet 
Protocol (IP) used by CL1 to send a request to the MM, is 
that all messages carry a return unique network address in 
the form of an Internet Protocol address (IPaddr.) exploiting 
which the MM can subsequently send a reply data message 
to the CL1, this eliminates any need for the CL1 to embed 
an address within the request as might be needed on other 
types of network or link. In step 13 the MM creates a record 
to represent game offer (GOR1) which contains the 
attributes from the request and the return unique network 
address of CL1. Records, sets of records and techniques for 
creating and maintaining them are well known in the com- 
puter programming art. In step 14 the MM sends a reply 
back to CL1 notifying CL1 that the match is not yet 
complete (step 14'). In step 15 CL1 waits for a request from 
MM. CL1 thus becomes the first member of a game match 
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yet to be completed. In step 16 the MM makes the contents 
of the game offer record available to other potential users. In 
step 17 MM waits for further requests from other clients. 

Referring to FIG. 2, in step 21, another instance of a client 
program (CL2) which is executing on a different user's 
computer from CL1 and also a different computer from MM, 
sends a request for a list of game offers to the MM. In step 
22 the MM receives this request. In step 23 the MM 
responds with information extracted from GOR1 that was 
created in step 13. In step 24 CL1 receives the response from 
MM which contains the game offer information from GOR1. 

Referring to FIG. 3, in step 31, CL2 sends to MM a 
request to be matched into the offer represented by GOR1. 
In step 32 the MM receives this request In step 33 the MM 
compares the attributes in the latest request sent by CL2 with 
those in GOR1 and if they do not match by whatever criteria 
the MM is programmed to use then CL2 is sent a message 
from MM that informs CL2 that it cannot join the offer 
represented by GOR1, at least not at this time (step 34). The 
use of programmed criteria to match requirements and sets 
of requirements is well known in the computer programming 
art. Assuming the attributes match, in step 35 the MM sends 
to CL2 a request to measure the communications attributes 
between CL1 and CL2. 

Referring to FIG. 4, in step 41, CL2 receives the latest 
described request from MM. In step 42 a determination is 
made by CL2 as to whether the request is a request to 
measure communications (comms.) attribute or is a rejec- 
tion. In step 43 CL2 measures the communications attributes 
of the data communications link between CL2 and CL1. 
Methods of measuring communications attributes are well 
known in the arts. Not all communications attributes are 
mutually orthogonal, though the especially important ones 
of latency, bandwidth and packet loss rate are indeed sub- 
stantially orthogonal. For example, CL2 could measure a 
data throughput rate attribute directly or CL2 could measure 
latency, bandwidth and packet loss rate separately and then 
calculate data throughput rate to a reasonable degree of 
accuracy (limited inter-alia by mensuration precision) from 
those three attributes by methods well known in the data 
communications arts. Another communications attribute is 
best case round trip time for a kilobyte sized message, this 
attribute is a function of latency, bandwidth and as a second 
order effect computer speed but is entirely independent of 
packet loss rate. Round trip times and methods of measuring 
them are also well known in the arts. In step 44 CL2 reports 
the results of measuring the attributes of the data commu- 
nications link between CL2 and CL1 back to MM. In step 45 
MM receives the message reporting the results of the 
comms. attribute measurement. 

Referring to FIG. 5, in step 51, the MM compares the 
communications attributes with the limiting values for com- 
munications attributes for the game recorded in GOR1 (or 
some predetermined default values for any limiting values 
for communications attributes absent from GOR1) and if 
(step 52) the communications attributes exceed any limiting 
values for communications attributes specified in GOR1 (or, 
in their absence predetermined defaults) according to pro- 
grammed criteria then in step 53 MM notifies CL2 that it is 
allowed to join the game offer and a further game offer 
record (GOR2) is created to record all the known attributes 
associated with CL2. Otherwise (step 54) CL2 is sent a 
message from MM that informs CL2 that it cannot join the 
offer represented by GOR1 (step 55). If not allowed to join, 
CL2 finishes. If allowed to join, CL2 waits for completion 
of a game match (step 56). 

Referring to FIG. 6, the MM must next determine whether 
or not the game match is complete. One vital criterion is 
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whether sufficient players are joined into the game offer 
(step 61). This embodiment uses the automatic match 
approach, so if a sufficient number of instances of client 
programs are joined then a time-out timer is started (step 62) 

5 for a predetermined interval such as 30 seconds during 
which time further clients may join the game provided the 
maximum allowed number is players is not reached (step 
63). Time-out timers are well known in the computer pro- 
gramming art. If a sufficient number of players is not yet 

10 joined then the time-out timer is not started yet and MM 
waits for more client (step 64). 

Until and unless the time-out timer expires further 
instances of client programs (CL3, CL4 etc) may join the 
game offer upon the same basis of negotiation as CL2 used, 

15 with the exception that the third and later clients (CLn) will 
be requested and required by the MM to measure and report 
back the communications attributes between the candidate 
instance of client program and all of the clients already 
joined (CL1 through CL(n-l)). 

20 Referring to FIG. 7, in step 71, when and if the time-out 
timer expires MM deems the game matched and sends 
messages to each of the clients (CL1 through CLn) to inform 
them of the successful completion of the game match. 
Otherwise MM takes no particular action in connection with 

25 the time-out timer (step 72). Upon receipt of the message 
informing them of the successful completion of the game 
match, each player's computer starts executing the game 
program instructions and each makes game data message 
exchanges between each user computer upon a Peer to Peer 

30 basis. At this point communication between the clients and 
the MM (which is a server) is no longer essential and 
gameplay proceeds. 

DESCRIPTION OF A FURTHER EMBODIMENT 
35 OF THE INVENTION 

By way of further illustration the present embodiment is 
an example subset of the general description of the present 
invention, the subset being directed to matchmaking for a 

40 game that uses multiple clients to a single server with early 
server binding. The network that this particular embodiment 
uses is again the well known Internet. The above general 
description of the present invention is entirely enabling of 
the invention generally and of this embodiment in particular 

45 to a practitioner ordinarily skilled in the arts. 

A matchmaker server program is used, an executing 
instance of this program (abbreviated to MM) resides on a 
server computer. Each computer user (abbreviated to user in 
this embodiment) launches an instance of a client computer 

50 program on his computer which computer is then a client 
computer. 

Referring to FIG. 8, in step 101, an instance of a client 
program (CLIO) sends a request to the MM. The request 
asks the MM to create a game offer and the request includes 

55 attributes of the various game and match preferences chosen 
by the user together with intrinsic attributes of the requested 
type of game and attributes of the hardware and software 
installed on the user's computer. The intrinsic attributes of 
the game include limiting values for communications 

60 attributes of links between clients and game servers (GSs). 
In step 102, the MM receives this request. In step 103 the 
MM creates a game offer record (GOR10) which contains 
the attributes from the request and the return unique network 
address of CLIO. In step 104 MM matches the attributes 

65 recorded in GOR10 with the attributes (if any) that game 
servers (GSs) have, at their own initiative, previously 
reported to MM and which MM retained in records created 
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for this purpose. In the case that this matching of game DESCRIPTION OF A STILL FURTHER 

server (GS) attributes to the attributes recorded in GOR10 EMBODIMENT THE INVENTION 

fails to identify a GS for which the attributes match GOR10 By way of fal ther illustration the present embodiment is 

adequately according to programmed criteria (step 105) men ^ example still further subset of the general description of 

CLIO is sent a message from MM that informs CLIO that s tne invention, this subset being directed to matchmaking for 

CLIO cannot join the offer represented by GOR10 (step a game that uses multiple clients to multiple servers with late 

1"°)- server binding. The network that this particular embodiment 

Referring to FIG. 9, in step 111 the MM sends to CLIO a uscs ^ agam tne well known Internet. The general descrip- 

request to measure the communications attributes between tion above is entirely enabling of the invention generally and 

CLIO and each of a shortlist of computers identified by the 3Q 0 f this embodiment in particular to a practitioner ordinarily 

unique network addresses of all of the potentially compat- skilled in the arts. 

ible GSs identified by MM in step 104 above. ims&n a matc hmaker server program is used, an executing 

Referring to FIG. 10, in step 121, CLIO receives one of instance of this program (MM) resides on a server computer, 

the latest described requests from MM. In step 122, a Each computer user (user) launches an instance of a client 

determination is made by CLIO as to whether the request is ^ computer program on his computer which computer is then 

a request to measure communications attributes or is a a client computer. 

rejection. If a rejection, then CLIO finishes. Otherwise, in An instance of a client program (CL20) sends a request to 

step 123 CLIO measures the communications attributes of the MM. The request asks the MM to create a game offer and 

each of the data communications links between CLIO and the request includes attributes of the various game and 

the shortlisted GSs. In step 124 CLIO reports the results of ^ match preferences chosen by the user together with intrinsic 

measuring the various communications attributes back to attributes of the requested type of game and attributes of the 

MM. In step 125 the MM receives this report. hardware and software installed on the user's computer. The 

Referring to FIG. 11, in step 131, the MM compares the intrinsic attributes of the game include hmiting values for 

communications attributes (for each path between CLIO and communications attributes of links between clients and 

each of the GSs reported on) with the limiting values in „ servers (GSs). Next the MM receives mis request. The 

GOR10 (or some predetermined default values for commu- 25 ™ U « 4t f % &™ offer "f 0 * GOR20) which contains 

nications attributes absent from GOR10) and if the commu- ^^TA^Tn 1 ?g? ^^T^T^^^l 

. 4 . „ -u * a *u I* *** i a ' *■ address of CL20. Then MM matches the attributes recorded 

nications attributes exceed the Wing values according to m GQR20 ^ ^ (if } ^ seryers 

programmed criteria specmed m GOR10 or, m their absence (G&) fa at ^ qwq ^ viousl rted to 

predetermined defaults (step 132) then in step 133 CLIO is 3Q MM and wfaich MM retamed m recQrds created for this 

allowed to create a valid game offer by recording the unique pur p 0S e. i n the case that this matching of game server (GS) 

network address of one of the qualifying servers in GOR10. attributes to the attributes recorded in GOR20 fails to 

This is termed early server binding. The server so selected identify a sufficient number of GSs (the number required is 

(in step 133) is termed the early bound game server (EBGS). 0 ne of the attributes passed by CL20 to MM) for which the 

If no qualifying server is found then CLIO is sent a message 35 attributes match GOR20 adequately according to pro- 

from MM that informs CLIO that MM cannot create a game grammed criteria then CL20 is sent a message from MM that 

offer (step 135) and GOR10 is destroyed (step 13Q. Meth- informs CL20 that it cannot join the offer represented by 

ods for destroying records are well known in the arts. GOR20. 

At CLIO, a determination is made as to whether MM has Next the MM sends to CL20 a request to measure the 

allowed CLIO to join game offer (step 137). If CLIO is 40 communications attributes between CL20 and each of a 

allowed, then CLIO waits for completion of game match shortlist of computers identified by the unique network 

(step 138). Otherwise, if not allowed to join, CLIO finishes. addresses of all of the potentially compatible GSs previously 

When further clients attempt to join the game offer identified by MM. 

represented by GOR10, they are requested by the MM to Then CL20 receives the latest described request from 

measure the communications attributes only between them- 45 MM - CL20 measures the communications attributes of each 

selves and the EBGS. On reporting these communications of lhe data communications links between CL20 and the 

attributes back to MM a determination is made as to whether shortlisted GSs. CL20 reports the results of measuring the 

those attributes exceed the limiting values according to various communications attributes back to MM. 

programmed criteria established above so that the client may The MM compares the communications attributes (for 

be allowed to join the game offer. 50 eacn P atn between CL20 and each of the GSs reported on) 

Ibis embodiment does not use the automatic match with me limiting values in GOR20 (or some predetermined 

approach, so MM informs CLIO of the progress of the match default values for communications attributes absent from 

as each client joins. When the user of CLIO is satisfied that GOR20) and if the communications attributes exceed the 

a sufficient number of players have joined the match then the limiting values according to programmed criteria specified 

user of CLIO can stimulate CLIO to send a message com- 55 m GOR20 ( or > in ^eir absence predetermined defaults) then 

manding MM to treat the match as completed. User stimu- MM creates for CL20 a valid game offer by recording all the 

lation of programs through means such as (for example) unique network addresses of all of the qualifying servers in 

keyboards or computer mice is well known in the computer GOR20. 

programming arts. The MM then sends each client a mes- The network addresses in this list of unique network 

sage informing the client of the completion of the match. 60 a ddresses is necessarily a subset of the shortlist referred to 

Upon receipt of the message informing them of the above, 

successful completion of the game match, the each player's The servers to be bound into the match are not yet selected 

computer starts executing the game program instructions because this embodiment uses late server binding, 

and makes game data message exchanges between the each If an insufficient number of qualifying servers are found 

user's computer and EBGS. At this point communication 65 then CL20 is sent a message from MM that informs CL20 

between the clients and the MM is no longer essential and that MM cannot create a game offer and GOR20 is 

gameplay proceeds. destroyed. 
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When further clients attempt to join the game offer (iii) adding to said set of computer objects said second 

represented by GOR20, they are requested by the MM to client instance; and 

measure the communications attributes between themselves (e) adding to said set of computer objects a member of 

and all of the servers listed in GOR20 as qualifying. said second server subset based on attributes associated 

On reporting these communications attributes back to s with each member of said set of computer objects. 

MM a determination is made as to whether those attributes 2 - ^ method of claim wherein one of said client 

exceed the limiting values for a sufficient number of servers attributes relates to capabilities of a computer system 

according to programmed criteria established above so that executing a corresponding one of said client instances 

the client may be allowed to ioin the game offer If the client e metno ° °* c ^ m wherein one or said chent 

. t1 , . . . « .i. c u- u m attributes relates to characteristics of at least one user using 

is allowed to ioin the came offer then any servers for which 10 c . , v . . , & 

it . J A . ..... /* * - . r . a corresponding one of said chent instances. 

the communications attributes of the further client fail to 4 ^ mc(h * d of daim x whcrein ^ ^ 

meet catena are removed from the list of qualifying servers ^^i^on attributes of a network link associ- 

m GOR20. Thus the hst of qualifying servers may become ated ^ a computer systern executing a corresponding one 

smaller and smaller as more clients join the game offer. 0 f client instances. 

This embodiment does not use the automatic match 15 5. The method of claim 4 wherein one of said commu- 

approach, so MM informs CL20 of the progress of the match nication attributes is bandwidth of said network link, 

as each client joins. When the user of CL20 is satisfied that 6. The method of claim 4 wherein one of said commu- 

a sufficient number of players have joined the match then the nication attributes is latency of said network link, 

user of CL20 can stimulate CL20 to send a message com- 7. The method of claim 4 wherein one of said commu- 

manding MM to treat the match as completed. At this stage 20 nication attributes is packet loss rate of said network link, 

the MM selects the GSs to be bound into the match. The 8. The method of claim 1 wherein one of said server 

servers most likely to result in good gameplay are chosen attributes relates to capabilities of a computer system 

according to programmed criteria and other factors includ- executing a corresponding one of said server instances, 

ing all the reported communications attributes. This is 9. The method of claim 1 wherein one of said server 

known as late server binding. The MM sends to each server 25 attributes relates to current load of a computer system 

a notification that the match is complete together with a list executing a corresponding one of said server instances, 

of the addresses of the servers selected. 10. The method of claim 1 further comprising the step of 

Upon receipt of the message informing them of the finding an instance of a server computer program from said 

successful completion of the game match, the each player's set of computer objects that minimizes average latency 

computer starts executing the game program instructions 30 between instances of server computer programs and 

and makes game data message exchanges between the each instances of chent computer programs belonging to said set 

user's computer and each bound server. At this point com- of computer objects. 

munication between the clients and the MM is no longer 11. The method of claim 1, further comprising the step of: 

essential and gameplay proceeds. ^ repeating said augmenting step to add a predetermined 

It is to be understood that even though numerous embodi- number of client instances to said set of computer 

ments and advantages of the present invention have been set objects. 

forth in the foregoing description, the above disclosure is 12. The method of claim 11, further comprising the step 

illustrative only, and changes may be made in detail yet of: 

remain within the broad principles of the invention. 4Q repeating said augmenting step to add client instances to 

Therefore, the present invention is to be limited only by the said set of computer objects for a predetermined time 

appended claims. interval. 

What is claimed is: 13. The method of claim 1 wherein said client attributes 

1, A method for creating a set of computer objects, said set include multiplayer game attributes, 

of computer objects comprising a plurality of client 45 14. The method of claim 13 further comprising a step of 

instances of chent computer programs together with a server providing a moderator for constructing said game attributes, 

instance of a server computer program selected from a set of 15. The method of claim 1, further comprising the step of: 

server instances, the method comprising the steps of: constructing a set of records, each record of said set of 

(a) receiving from a first chent instance a first request to records comprising said server attributes. 

be joined into said set of computer objects, said first 50 16. The method of claim 15, wherein step (b) comprises 

request comprising first client attributes associated with the step of: 

said first client instance; selecting a record subset of said set of records in response 

(b) selecting a first server subset of said set of server to said first request based on said first client attributes, 
instances in response to said first request based on said 17. The method of claim 15, wherein step (ii) comprises 
first client attributes; 55 the step of: 

(c) creating said set of computer objects consisting of said removing from said record subset a further subset of said 
first client instance; set of records in response to said second request based 

(d) augmenting said set of computer objects with a second on said second client attributes. 

client instance of a chent computer program, compris- 18. A system for creating a set of computer objects, said 

ing the steps of: 60 set of computer objects comprising a plurality of client 

(I) receiving from said second client instance a second instances of client computer programs together with a server 

request to be joined into said set of computer objects, instance of a server computer program selected from a set of 

said second request comprising second client server instances, the system comprising: 

attributes associated with said second client instance. (a) means for receiving from a first client instance a first 

(ii) removing from said first server subset a second 65 request to be joined into said set of computer objects, 

server subset in response to said second request said first request comprising first client attributes asso- 

based on said second client attributes, and ciated with said first chent instance; 
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(b) means for selecting a first server subset of said set of 
server instances in response to said first request based 
on said first client attributes; 

(c) means for creating said set of computer objects s 
consisting of said first client instance; 

(d) means for augmenting said set of computer objects 
with a second client instance of a client computer 
program, comprising: jq 
(i) means for receiving from said second client instance 

a second request to be joined into said set of com- 
puter objects, said second request comprising second 



18 

client attributes associated with said second client 
instance; 

(ii) means for removing from said first server subset a 
second server subset in response to said second 
request based on said second client attributes; and 

(iii) means for adding to said set of computer objects 
said second client instance; and 

(e) means for adding to said set of computer objects a 
member of said second server subset based on 
attributes associated with each member of said set of 
computer objects. 

***** 
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